Preparation of a software configuration using an XML type programming language

ABSTRACT

Configuring software for a target comprises preparing a command file which specifies a subset of components selected from a group of components, and parameters for tuning at least some of the selected subset of components. The command file is written using a single object-oriented programming language, capable of managing tree structures of objects, preferably an XML type language, having a Document Type Definition enabling it to work as a programming language. An image file is prepared from the command file, to be loaded on the target.

BACKGROUND OF THE INVENTION

[0001] This invention relates to computer technology.

[0002] The operating system (OS) named ChorusOS (SUN MICROSYSTEMS, STQUENTIN EN YVELINES, France) is a realtime embedded OS, flexible as tothe hosting hardware. This implies that it has to be installed andconfigured on a variety of computer platforms.

[0003] For being installed on a particular machine (“target”), ChorusOShas to be configured, i.e. prepared depending upon the targetcharacteristics, and the application software to be supported. After thepreparation, the size of the program code may range from 10 kilobytesfor a portable machine to several megabytes for a telecom switch, forexample.

SUMMARY OF THE INVENTION

[0004] Existing versions of ChorusOS use a palette of differentprogramming tools to enable the selection of the desired elements ofChorusOS for a particular target, and for adapting the same to thattarget, as needed. More precisely, different specific languages wereused for “tuning” the configuration, for defining features thereof, andalso for defining the memory layout thereof. Generally, discussions aremade in this application in the context of ChorusOS, but the presentinvention is widely applicable across ohter systems.

[0005] This invention intends to improve the preparation of a softwareconfiguration for a given machine or target.

[0006] One object of this invention is to provide a single programminglanguage common for substantially all steps of the preparation of asoftware configuration.

[0007] Another object of this invention is to provide such a singleprogramming language in a form which is simple, standard and flexible inuse, preferably as an implementation of the extended Markup Language(XML).

[0008] A further object of this invention is to enable the constructionof a hierarchically organized tree of data representing the softwareconfiguration.

[0009] Still another object of this invention is to enable thepreparation of a software configuration to be made on a dedicatedmachine, with the help of a Graphic User Interface (GUI).

[0010] There is proposed a method of configuring software for a target,comprising:

[0011] a. preparing commands which specify:

[0012] a1. a subset of components selected from a group of components,

[0013] a2. parameters for tuning a least some of the selected componentsin said subset, and

[0014] b. preparing an image file from the command file.

[0015] The above method is of particular interest in providingcross-platform compatibility, in accordance with the invention.

[0016] According to an aspect of this invention, step a. compriseswriting the commands in a command file using a single object-orientedprogramming language, capable of managing tree structures of objects.Preferably, the command file is an XML file, and the single programminglanguage is specified using an XML document type definition, having atleast one nestable element predefined to receive an attribute pointingon a file. Other features of the XML document type definition will bedefined hereinafter.

[0017] Advantageously, the command file and image file are prepared on ahost system separate from the target. Then, preferably, step a) furthercomprises: a3. loading the subset of components on the target. Fortarget operation, the method further comprises the step c. of loadingthe image file in the target.

[0018] Minimally, the image file includes at least an operating systemkernel. It may also include an operational file system. Preferably, theimage file also defines parameters, actions, and memory layout of thesoftware.

[0019] According to another aspect of this invention, step b. comprises:

[0020] b1. preparing a make file from said command file, and

[0021] b2. building said image file using said make file.

[0022] The invention also encompasses a computer program product,comprising the group of components of step a1., the code of the XMLdocument type definition in claim 2, and the code for implementing stepb, or portions of these codes usable in a commercially availablesoftware environment. The computer program product may further comprisecode for implementing step a3, and/or code for implementing step c.

[0023] Still in another aspect of this invention, there is provided asystem for configuring software for a target, comprising a host having

[0024] a. A group of components;

[0025] b. Software for preparing a command file which specifies

[0026] b1. a subset of components selected from the group of components,

[0027] b2. parameters for tuning at least some of the selected subset ofcomponents,

[0028] b3. loading of the subset of components on the target, saidsoftware using a single object-oriented programming language, capable ofmanaging tree structures of objects,

[0029] c. Software for preparing an image file, and

[0030] d. A link for loading the image file and the selected subset ofcomponents in the target.

[0031] The above system is subject to additional features similar tothose enunciated on the basis of the method.

[0032] This invention also covers a command file from which an imagefile for a target can be prepared, the command file specifying

[0033] a. a subset of components selected from a group of components,

[0034] b. parameters for tuning at least some of the selected subset ofcomponents,

[0035] c. loading of the subset of components on the target.

[0036] This invention further covers a computer program productcomprising a computer-readable medium, having a command file from whichan image file for a target can be prepared, the command file specifying

[0037] a. a subset of components selected from a group of components,

[0038] b. parameters for tuning at least some of the selected subset ofcomponents,

[0039] c. loading of the subset of components on the target.

[0040] This invention still further covers the combination of thecommand file with the corresponding image file.

BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Other characteristics and advantages of the invention will appearin the light of the detailed description below and the associateddrawings in which:

[0042]FIG. 1 is a general diagram of two computer stations in which thisinvention is applicable;

[0043]FIG. 2 shows the memory main components in host station 100 ofFIG. 1;

[0044]FIG. 3 shows software modules involved in configuring a targetstation;

[0045]FIG. 4 shows how an ECML file may be submitted to syntactic andsemantic analysis;

[0046]FIG. 5 is a flow chart showing the main steps of the configurationprocess, as implemented before this invention;

[0047]FIG. 6 is a flow chart showing the main steps of the configurationprocess as implemented in accordance with this invention; and

[0048]FIG. 7 is a flow chart showing step 540 of FIG. 6 in more detail.

[0049] Additionally, features of the new language used in this invention(ECML) are defined in Exhibits I and II; Exhibit III shows a portion ofan ECML configuration file.

[0050] Making reference to a language also imposes certain conventionsin notation. In the detailed description:

[0051] the quote sign “ is used as character string delimiter whereverdeemed necessary for clarity (e.g. “TITLE” hereinafter),

[0052] where the language name is an abbreviation of the current name,square brackets frame the rest of the current name (e.g. ENUM[eration]hereinafter).

DETAILED DESCRIPTION

[0053] Existing versions of ChorusOS are defined in “Sun EmbeddedWorkshop, ChorusOS Technical Overview”, CS/TR-96-119, SUNMICROELECTRONICS, Palo Alto, Calif. 94303, USA.

[0054] An instance of the ChorusOS operating system always includes thecore executive component of ChorusoS. Optional components in theoperating system provide additional services. The following list of suchservices is not meant to be complete, as other services may be provided:

[0055] Actor Management

[0056] Scheduling

[0057] Memory Management

[0058] Proxy Management

[0059] Inter-thread communication

[0060] Time Management

[0061] Inter-process communication

[0062] Local Access Points (LAP)

[0063] Debugging

[0064] Initialization and command interpreter (C_INIT)

[0065] File System Options

[0066] I/O Management

[0067] Networking

[0068] Administration.

[0069] Graphic user interface (GUI).

[0070] These optional components can be added to, or removed from, aninstance of the ChorusOS operating system. In this way, the operatingsystem can be very finely tuned to meet the requirements of a givenapplication or environment.

[0071] Each API function in the ChorusOS operating system is containedin one or more of the configurable components. As long as at least oneof these components is configured into a given instance of the operatingsystem, the function is available to be called. However, certain purelibrary functions are independent of any specific component and arealways available.

[0072] In FIG. 1, target T is the computer intended to receive ChorusOS.The target board 800 has a processor 801, elementary firmware 802, amemory 805 and peripheral devices 820, which may belong to a customdesigned peripheral board. The configuration process concerning thetarget is performed from a host or installing computer H. The host board100 has a processor 101, e.g. a SPARC (a product and trademark of SUNMICROSYSTEMS), an operating system 102, e.g. Solaris (a product andtrademark of SUN MICROSYSTEMS), a memory 105 (encompassing both workingmemory and mass memory, i.e. hard disk, where appropriate), and mayfurther include the usual display 110, mouse (or other pointer) 111 andkeyboard 112.

[0073] An appropriate link 900 is made between the host and the target,under control of firmware commands on the target side.

[0074] As shown in FIG. 2, a portion of memory 105 (RAM or DISK)contains software configuration data, i.e. various software modulesserving as tools for the configuration process, or as constituents ofthe software to be installed.

[0075] Building and configurating such a system requires the selectionand configuration of the kernel and operating system generic portions,and also of a processor family dependent portion. Additionally (FIG. 3),it includes the selection and configuration of components defining:

[0076] binary modules corresponding to a variety of supported processorsand processor architectures,

[0077] Board Support Packages (BSP), supplied by the applicant companyfor a variety of different custom boards,

[0078] pieces of code (so-called “drivers”) for the board 800, and

[0079] application software as desired.

[0080] Thus, configuring the OS for a particular machine means:

[0081] selecting between a light or full version of the OS, with a verylarge number of intermediate situations,

[0082] ensuring coherence of the OS before it may be launched by the OSuser.

[0083] This configuration and build process encompasses providing avariety of information ranging from the selection of OS modules to thedefinition of the memory layout of the deployed system on the target.

[0084] Concretely, the primary result of the configuration process is an“image file” (also termed “archives”). When installed on the targetmachine (e.g. in epROM or flash memory), the image file is capable(after suitable initialization, like rebooting) to have it operateconsistently in the desired hardware and software configuration.

[0085]FIG. 5 shows diagrammatically the configuration process as used inprevious versions of ChorusOS. Defining the configuration (500) is splitinto defining different portions of the configuration, 501 for the“features”, 502 for the “tunable”, 503 for the “archive memory layout”(these concepts will be defined later), etc. The portions areindividually checked in 511, 512, 513, etc. Then, they are cross-checkedin 520. If the checking is not entirely satisfactory, the whole processhas to be resumed (except where the error is restricted to very fewthings, which the operator can identify and correct). Multiple languagesand configuration tools were used to handle this diversity ofinformation. Each aspect of the configuration is covered by a specificlanguage and tool. On the one hand, this approach leads to thespecialization of each language and tool to its own domain, resultinginto simple syntax, and simple tools. On the other hand, it is difficultto share information between tools, and to take into account new typesof information. This implies a sophisticated mechanism to bind all thetools together.

[0086] If the checking is satisfactory, a “make file” is prepared (530),using the various portions of configuration having been prepared. The“make file” is an ordered and coherent list of operations to be made toobtain an image file at 540. The image file is then loaded on the target(550), and, usually, tested (560). Again, the test may result intoresuming the whole process.

[0087] There is a current trend towards a binary model (delivery ofsoftware modules in binary form). It increases the complexity of theconfiguration process. As time goes, more and more component providers(board support packages, drivers and so forth) are required to obtain arunning system. This puts more emphasis on the specification ofconfiguration data. Furthermore, to reduce the complexity of theconfiguration process, graphical tools should be developed to complementcommand line tools.

[0088] In the present invention, the following new capabilities aresought:

[0089] The applicant company provides Board Support Packages (BSP) for anumber of peripheral boards available from various independent hardwarevendors. It has been found desirable to supply the BSPs in a form whichcomprises binary code dedicated to the board itself, and source code forthe platform dependent portions of the BSP, e.g. Application ProgramInterfaces or APIs.

[0090] distinguishing between programming APIs (e.g. in Posix), andconfiguration APIs. Configuration is here intended to be understood in avery generic fashion, i.e. all the information that is not purelyprogramming API and that is required to build the target system andadapt it to a specific hardware and to a specific usage.

[0091] Accordingly, in the present invention, configuration will cover:

[0092] feature configuration, i.e. the appropriate subset of componentsrequired in the system, e.g. scheduling classes, memory managementsupport,

[0093] tunable configuration, e.g. specific system values, number ofthreads in the kernel, size of communication buffers,

[0094] memory layout of the various components of the system,

[0095] driver properties,

[0096] third party application configuration.

[0097] In accordance with an aspect of this invention, a singleconfiguration programming language has been designed for processing suchfolders as objects. Preferably, this single configuration programminglanguage is based on the XML language standard, and named “EmbeddedComponent Markup Language” (ECML).

[0098] XML (for extended Markup Language) is a recent hypertextmetalanguage standard, specified by the XML working group. Forunderstanding the XML aspects of this invention, reference is made tothe XML recommendations, available on the INTERNET athttp://www.w3.org/TR/REC-xml, or to the booklet “XML Pocket References”,Robert ECKSTEIN, O'REILLY, U.S.A, October 1999.

[0099] The basic markup principle of XML is as follows:

[0100] let “TITLE” be a selected character string,

[0101] in the corresponding XML document, what is between “<TITLE>” and“</TITLE> is an “element”,

[0102] a Document Type Definition (DTD) determines what that element maycontain (including other nested elements), and its attributes.

[0103] Until now, XML proposals have been essentially text-based. Thus,an XML parser will read the DTD and the XML file, and use the markups totrigger actions referred to the XML document itself: e.g. print “TITLE”and “AUTHOR” in different font sizes.

[0104] By contrast, the newly proposed ECML language is intended to be aprogramming language. This raises new problems, since the actions beingtriggered by the program will be external to the XML document itself.However, as it will be seen, ECML considerably simplifies theconfiguration and building process of ChorusOS based systems.

[0105] The DTD for ECML is given in Exhibit I. A DTD has the same markupprinciple as XML itself, however with slightly different syntax rules,and reserved words like #PCDATA. The DTD expressions are enclosedbetween “<!XXXXX” and “>”, where “XXXXX” is a keyword, e.g. “ELEMENT”,and the rest is a name, followed with one or more other arguments. Theexpressions are case-sensitive. The DTD provides a formal definition ofthe elements with <!ELEMENT . . . >and of their attributes, with<!ATTLIST . . . >), together with the relationship among the dataelements. An <!ENTITY # . . . >clause builds a parameter entity forinternal use in the DTD. Finally, comments are enclosed between “<! - -” and “ - - >” markups. The comments have been supplemented withalphanumeric identifiers, for purpose of description. In Exhibit I:

[0106] sections A1 and A2 prepare entities for the DTD, defining what a“container” and a “content” will be.

[0107] sections B uses the “container.mdl” and “content.mdl” entities todefine the element “configuration” and its attributes, while definingfurther entity “config.mdl”.

[0108] section C uses the “container.mdl” and “content.mdl” entities todefine a further entity “folder.mdl”, and prepares elements “folder”,and “folderRef”.

[0109] section D prepares the element “description”.

[0110] section E defines the entity “type.mdl”, while sections E1through E6 prepares the elements corresponding to various types ofvariables: “bool”, “int”, “string”, “enum”, “struct”, “list”.

[0111] section F defines the entities “boolExpr.mdl” and “expr.mdl”, andprepares the elements corresponding to the boolean expressions “and”,“or”, “not”, to the boolean/arithmetic expressions “equal”, “notEqual”,and to “ifdef”.

[0112] sections G1 through G5 prepare the elements/attributes for givinga value to a variable, as a constant “true”, “false”, “const”, or byreference to another object “var”, “ref”, “vstring”.

[0113] section H defines the entity “field.mdl”, and prepares theelement “field”.

[0114] section I prepares the element “condition”.

[0115] section J defines the entity “definition.mdl”, and prepares theelement “definition”, and the elements “feature” and “tunable”, whichare directly related to software configuration.

[0116] section K defines the entity “setting.mdl”, and prepares theelement “setting”, for assignment of a value to a variable.

[0117] sections L and M prepare the elements “constraint” and“parameter”.

[0118] section N prepares the elements “action” and “application”.

[0119] section O prepares the element “typeDef”, for definable types ofvariables.

[0120] section P prepares the elements “using”, “value”, and “default”.

[0121] Exhibit II shows a few examples of program statements using ECML.In the beginning:

[0122] II.1.1 and II.1.2 respectively define a boolean variable“my_variable1”, set to true, and an integer variable “my_variable2”,having the value 1024.

[0123] II.1.3 shows how “my_variable1” may be later set to false.

[0124] II.1.4 shows how “my_variable4” may be created with the value of“my_variable2”.

[0125] ECML allows the definition of actions. Each action ischaracterized by:

[0126] its “name”, a string of characters,

[0127] its “application”, a string of characters,

[0128] its “parameter”, a reference to a defined variable.

[0129] Example II.2 defines an action “my_action”, associated to theapplication “my_application”, which will be called with the variable“my_variable”.

[0130] The “action” is the entry point for calling application plugins,while binding these tools to descriptions. When parsing a configurationECML file, application plugins are called with associated parameters. Adescription can be optionally associated with an action. The expressionis evaluated if there is no condition associated with the constraint orif the condition associated with the constraint evaluates to true.Application processing is tool specific. The “application” elementdefines the plugin that should be called. The parameter associated withthe application can be defined using a local definition or a referenceto a defined variable.

[0131] Example II.3.1 shows how a new type “my_type” is defined. Thistype is a structure that contains two fields “my_field1” of type integerand “my_field2” of type boolean. Example II.3.2 illustrates thedefinition of a variable of type “my_type”.

[0132] In example II.4, if the variable “my_condition” evaluates totrue, the variable “my_variable” will be defined; if the variable“my_condition” evaluates to false, the definition container will not beprocessed. Generally, ECML allows association of a condition with anelement; then, the element is processed if and only if the conditionevaluates to true.

[0133] In order to check consistency between variables, ECML uses“constraints”, each characterized by a boolean expression. In exampleII.5, if the variable “my_condition” evaluates to true, the constraintis verified. If the variable “my_conditions” evaluates to false theconstraint evaluates to false.

[0134] Example II.6 shows an AND logical function with variables“my_condition1” and “my_condition2”.

[0135] ECML provides support to organize the information describedthrough “folder” and “folderRef” elements in a hierarchical manner. The“folder” element is the container element that provides encapsulation ofother elements. A “folder” is characterized by its “name”, a string ofcharacters. Example II.7.1 defines a folder “my_folder”, containing twofolders “my_subfolder1” and “my_subfolder2”. The “folderRef” element ofII.7.2 is the container element that is used to create a reference toanother file. The referenced file “filename” is embedded for processingin the body of the folder “my_folder” at the location of the reference.Relative paths are assumed to be relative to the directory containingthe file being parsed.

[0136] The above reflects the fact that, when using XML, any languageelement must be then be defined, with its own markups, in contrast withother programming languages. This results some complexity, since e.g.example II.1. needs four lines, in lieu of a program statement oftenwritten as follows:

my_variable=TRUE

[0137] Despite that complexity, it has been found possible to elaboratean XML based programming language, at least for use in configuringsoftware. Furthermore, this approach has the advantage of providing theprogram as a fully structured text, in which automatic tools (programs)may later easily and safely fetch any information they require.

[0138] As shown in FIG. 4, the ECML file may be submitted to a syntacticanalyser 211, using the corresponding DTD 201. If desired (fornon-developers), it may be submitted to a semantic analyser 212, using alibrary 202 containing the semantic rules to be applied.

[0139] It results from the above description that ECML provides, interalia, support for:

[0140] defining a variable (integer) with a mechanism (or “trigger”) tocheck its value with respect to a minimum and a maximum;

[0141] defining constraints between variables, using boolean calculus;

[0142] associating the definition of a variable to conditions expressedby other variables;

[0143] later updating of a variable having already be defined;

[0144] managing lists, in the form of an object model;

[0145] organizing the configuration in a hierarchical manner in multiplefiles;

[0146] organizing the naming space of variables (an XML feature).

[0147] Together, these two last mentioned organizing tools permit tocope with the diversity of managed information and the number ofcomponent providers.

[0148] Thus, according to a basic concept of this invention, all thenecessary information or data for the OS configuration is arranged as atree-structured set of “folders”, such that any folder has a parentfolder, starting from a head folder. Through “folderRef”, a folder maybe connected to an independent file. Certain folder files may bemodified. This enables the folders to includes files of differentorigins, which have to be organized for proper operation. Thus, theapplicant felt the need for an adequate structured sequentialprogramming language.

[0149] An example of a much simplified ECML file will now be described,with reference to Exhibit III:

[0150] Lines 4-6 are the usual XML header, defining the XML version andthe applicable DTD.

[0151] Then, line 8 creates a folder “Kernel Configuration”, having a“folderRef”.

[0152] Lines 11-30 create a [sub] folder “Core Executive”, in which thefeature “HOT_RESTART” is disabled, the feature “USER_MODE” is enabled,and the feature “ROUND_ROBIN” is disabled.

[0153] Lines 32-60 create a [sub] folder “Kernel core tunables”, inwhich the tunable “chorusSiteId” is set to integer 0, the tunable“kern.exec.maxCpuNumber” is set to integer 1, the tunable“kern.exec.maxActorNumber” is set to integer 64, and the tunable“kern.exec.maxThreadNumber” is set to integer 128.

[0154] Lines 62-80 creates a [sub] folder “Virtual Address Space”. Itwill be processsed only if the variable “VIRTUAL_ADDRESS_SPACE” is true.If so, a feature “ON_DEMAND_PAGING” is created, which will be processedonly if the variables “VM available” and “PRM_available” are both true.The feature “ON_DEMAND_PAGING” is set to false.

[0155] The configuration process will now be described, using theterminology of ChorusOS. The discussion of ChorusOS is exemplary only,and the invention is not limited to ChorusOS.

[0156] Generally, configuring ChorusOS firstly comprises selectingcomponents, using the boolean variables called FEATURES; this resultsinto a LIST of components.

[0157] The configuration process comprises three other levels of systemconfiguration:

[0158] a) Resources. For the list of selected components of FEATURES, itis possible to fix the amount of resources which are to be managed. Thisuses variables, representing tasks, buffers, and other parameters foradapting the target system to its own desired configuration (for examplea pager needs only a small number of internal OS processes or actors).Some of the variables (the “tunable”) are preferably “tuned” to avoidspoiling resources which are of no use in the target as desired. Thus,it is also possible to set the value of those tunable variables, forexample, the amount of memory reserved for network buffers. The TUNABLEvariables are mostly integer and string variables, but may also bedefined using an ENUM[eration] type variable. The TUNABLE may belong tothe components themselves, or be various resource (e.g. memory)parameters. They usually are an integer having minimum and maximumvalues, e.g. to represent the network buffer size, while avoidingmeaningless configuration such as a negative value therefor.

[0159] b) Boot Actors. It is possible to include additional actors inthe memory image that is loaded at boot time. The list management, donein the form of an object model, simplifies significantly the descriptionof a list and reduces the possibility of mistakes. Here, for example,including additional actors in the memory image uses list management:more information must be associated with each actor added into the imagesuch as linking address, actor type, and so forth. This is a refinementof the target image building process done according to this invention.

[0160] c) Environment. System-wide configuration parameters can be fixedby setting UNIX-like environment strings, which the operating system andactors retrieve when they are initialized. For example, an IP addresscan be defined globally by setting LOCAL_INADDR to ‘192.33.15.18’. Thisimplies allowing for definition and management of variables such asLOCAL_INADDR. In order to check the correctness of the configurationstatically, these variables should be typed, possibly with definabletypes

[0161] This is monitored by configuration tools, which take care of anyhidden dependencies or possible incompatibilities. An element having its“visible” set to “no” serves that purpose.

[0162] ECML enables to simply associate the definition of variables toconditions expressed by other variables. This is very useful, since asoftware configuration largely depends on itself: for example, theEthernet driver should be tuned if and only if it has been selected.Thus, a “driver_to_be_tuned” boolean variable may be defined from a“driver_selected” boolean condition.

[0163] With the ability to define constraints between variables, usingboolean calculus, it becomes possible to use a sophisticated rule-engineto check the validity of a configuration. This rule-engine implementsboolean calculus on features, based on boolean expressions. Thismechanism provides support for checking feature dependencies such as:“Ethernet driver is required by TCP/IP feature”.

[0164]FIG. 6 shows diagrammatically the new configuration process, usingECML. Defining the configuration (500) is now simply writing an ECMLfile 509, described in further detail below. The checkings reduce to asingle step 529, a part of which may be implemented in real time duringthe ECML file edition. The rest of the steps is similar, however withvarious significant changes, like the modular structure of the objectsor folders being called or used by the make file, and the possibilityfor the make file execution to interact with the ECML file (not shown inFIG. 6).

[0165] Preferably, a set of predefined configurations 508 (“profiles”)are provided. The configuration process is then decomposed in two steps:

[0166] selection of a predefined configuration. As seen hereinafter, theconfiguration operator defines the desired configuration using an XMLtext editor, together with a command line tool and/or a graphical tool,for launching “actions” of the configuration producing system. The“actions” comprise:

[0167] designating one or more folder object files or FOF, and

[0168] checking that the designated FOFs are coherent with previouslydesignated FOFs and between themselves.

[0169] modification of the selected configuration, if desired, with thecapacity to restore the predefined values. Therefore, ECML and theassociated tools provide a mechanism to manage modifications made to theconfiguration.

[0170] As shown in FIG. 7, the ECML file 509 is written under control ofthe operator 400, preferably with the help of configuration assistanttools 528.

[0171] The information accessible to the configuration operator may notbe sufficient to this effect, and the system may also include “hidden”information comprising:

[0172] a list of available objects,

[0173] a list of “tuning” tools defining how those of the objects whichare “tunable” may be tuned.

[0174] At least at the level of developers (e.g. for the predefinedconfigurations), the ECML file may be edited by using a standard editor,that can be completed with XML specific modes (such as “emacs”, a texteditor of the GNU).

[0175] The ECML file may also be displayed through standard browsers,adapted to work with the XML language. Optionally, the browser mayreceive extensions to handle XML, in order to complete the graphicaltools. Therefore, a translator from ECML to HTML may be included,enabling use of existing graphical tools functions.

[0176] As an XML file, an ECML file may be processed or parsed using asoftware module named “XML processor”, enabling access to the datacontent and to the structure thereof. The parsing may be based on C++ orJava tools, used during the building process of the system. In thisdescription, the XML processor further acts as some kind of programinterpreter, for performing the desired steps of software configuration,in the example being described here. Each such step may be executed likea command line (command line mode), or the steps may be piloted using agraphic user interface, i.e. graphical tools, mode targeted to end-usersto configure the system.

[0177] The basic processing of ECML files in command line mode is splitin two phases:

[0178] parsing the ECML file, which in turn involves two processes:

[0179] XML parsing

[0180] semantic analysis

[0181] tool invocation.

[0182] The semantic analysis may be made using an XML semantic analyser,taking into account the needs shown in the DTD. If desired, a syntacticanalysis may be made using an XML syntactic analyser like JAVA XML soldby the applicant.

[0183] The result of the processing is a list of defined variables. Asimple interface is provided to browse this list of variables. Thisinterface is used by the tools involved in obtaining configurationinformation.

[0184] ECML integrates easily into a Java graphical tool, which is anadditional key evolution to simplify the overall process of building thesystem, and more easily allows future evolution of configurationinformation.

[0185]FIG. 7 shows on more detail how the image file is built, byapplying the make process 540 to the “make file” 535.

[0186] Basically, the make file comprises individual steps of action.Each such step 541 fetches a particular software module (a file in thehost) which is first compiled at 542, if not already available in binaryform.

[0187] After compilation, the modules then have to be linked at 544.

[0188] In the case 545 of a fixed (invariable) software module, thelinking step is direct. For the case 546 of a configurable softwaremodule, the linking step will access the ECML file 509, as necessary toobtain the information defining the particular configuration parametersof the software module being linked. This uses the folder organizationof the ECML file, and the value(s) in the “TUNABLE” object for thesoftware module being processed. This is another advantage of ECML.

[0189] When the image file is finalized at 548, step 549 preferablyinteracts with ECML file 509, essentially to update it with furtherinformation relating to the image file itself, including the futurememory layout in the target (as it will be explained in more detailhereinafter). Thus, the ECML file contains not only what is necessary tobuild the make file, and then the image file, but also information ashow the image file is in itself, and may be installed in the targetmemory. This is still another advantage of ECML, and is of interest fortesting purposes. If required, step 549 also defines the additionalcomponents, to be loaded by the image file.

[0190] Later, a test step 560 may also add debug-oriented information561 into the ECML file, thus rendering it to be a completerepresentation of the whole configuration process, including thetesting.

[0191] In the example of ChorusOs, a module named MKIMAGE enables tomake an image file for the target. The system image is the initial stateof the target board's physical memory. It contains a set of filesorganized in one or more memory banks. When the target system isdeployed, some of the system image memory banks are burnt intonon-volatile physical memory. The rest can be downloaded from a localdevice or from the network by the initial loader.

[0192] More precisely, in the example, the MKIMAGE command builds abinary file called “bootconf”, and containing a data structure alsocalled BootConf, which describes the system image contents and layout.MKIMAGE includes the bootconf binary file in one of the system imagememory banks. When the target will be started, the initial loader willboot the OS, jumping to the entry point of bootconf binary. In fact,“bootconf” is a board-independent program that gets control from theboard-specific initial loader and transfers control to theboard-specific bootstrap program. The initial loader may pass aboard-dependent parameter to the bootstrap.

[0193] Thus, MKIMAGE creates the system image as defined in the ECMLconfiguration file. The configuration may specify a list of memorybanks, and, for each particular bank, a symbolic name, a base address,and a size limit. Upon request from the configuration file, MKIMAGE mayalso organize at least some of the memory banks as a file system volume.The configuration file may also specify a list of files (components) tobe included in the system image, and, for each particular file, the bankwhere the file will be stored. In addition, relocatable files may beprocessed; for such a file, the configuration may specify how the filemay be relocated, when stored in a memory bank.

[0194] Accordingly, the configuration file enables to closely describeand visualize the fine organization of the target.

[0195] In other words, after the configuration has been entirely defined(509) and checked (529), a succession of processing modules (“tools”)may be involved during the process of building an image file (530,540):

[0196] a first tool (546) extracts tunable information from theconfiguration ECML file and generates the appropriate code to implementthe tunables;

[0197] a second tool (549) builds the appropriate object list, based onthe list of components used in the system;

[0198] a third tool (548) builds the image file to be downloaded to thetarget, based on the image description.

[0199] It will be seen that the ECML file acts as a commoninfrastructure between those tools. Each tool uses a subset of theinformation. Therefore, ECML additionally provides entry points fortools.

[0200] This invention also covers the proposed software code itself,especially when made available on any appropriate computer-readablemedium. The expression “computer-readable medium” includes a storagemedium such as magnetic or optic, as well as a transmission medium suchas a digital or analog signal. The software code basically includes thecode for use in the configuration process itself. It may also include atleast some of the group of software components to be installed. Theinvention also covers the code (image file) obtained as a result of theconfiguration process, both alone and in association with one or morecorresponding XML files, with or without the corresponding DTD, whichmay obtained through different channels.

[0201] The invention has particular interest in the context ofconfiguring software and similar applications. However, the conceptsused in building a programming language from XML have interest inthemselves. Thus, these aspects are also covered, inter alia in the formof an XML processor, comprising:

[0202] a parser for acquiring at least a portion of an XML type file,and a corresponding document type definition, and

[0203] an analyser for identifying objects in said portion of said XMLtype file, said objects comprising variables, values, operations,conditions and commands. Other described features also intervene inenabling an XML type file with a DTD to be used as a program file. TheDTD enabling this is also part of the invention, whether presented apartfrom the XML file, or at least partially incorporated therein. ExhibitI - ECML DTD <!-- A1. Container --> <!ENTITY % container.mdl’(description?,condition?,typeDef*, (definition|feature|tunable)*,setting*,action*,constraint*)’> <!-- A2. Content --> <!ENTITY %content.mdl ’(folder|folderRef)*’> <!-- B. ChorusOS image config. --><!ENTITY % config.mdl ’%container.mdl;,%content.mdl;’> <!ELEMENTconfiguration (%config.mdl;)> <!ATTLIST configuration name CDATA#REQUIRED > <!-- C. Folder --> <!ENTITY % folder.mdl ’%container.mdl;,%content.mdl;’> <!ELEMENT folder (%folder.mdl;)> <!ATTLIST folder nameCDATA #REQUIRED visible (yes|no) #IMPLIED configurable (yes|no)#IMPLIED > <!ELEMENT folderRef EMPTY> <!ATTLIST folderRef xml-link CDATA#IMPLIED href CDATA #REQUIRED actuate (auto|user) #IMPLIED visible(yes|no) #IMPLIED > <!-- D. Elements description --> <!ELEMENTdescription (#PCDATA)> <!-- E.Type --> <!ENTITY % type.mdl’bool|int|string|enum|struct|list|type’> <!-- E1. Boolean constant --><!ELEMENT bool EMPTY> <!-- E2. Integer constant. --> <!ELEMENT intEMPTY> <!ATTLIST int min CDATA #IMPLIED max CDATA #IMPLIED> <!-- E3.String --> <!ELEMENT string EMPTY> <!ATTLIST string kind(filename|dirname) #IMPLIED> <!-- E4. Enumeration --> <!ELEMENT enum(const+)> <!-- E5. structures --> <!ELEMENT struct (field+)> <!ATTLISTstruct key CDATA #IMPLIED> <!-- E6. lists --> <!ATTLIST list ref-only(yes|no) #IMPLIED> <!ELEMENT list (%type.mdl;)> <!-- F. Expression --><!ENTITY % boolExpr.mdl ’var|true|false|and|or|not|equal|notEqual|ifdef|imply|onlyOne’><!ENTITY % expr.mdl ’ref|vstring|const|%boolExpr.mdl;’> <!ELEMENT and((%boolExpr.mdl;)+)> <!ELEMENT or ((%boolExpr.mdl;)+)> <!ELEMENT not(%boolExpr.mdl;)> <!ELEMENT equal ((%expr.mdl;), (%expr.mdl;))><!ELEMENT notEqual ((%expr.mdl;), (%expr.mdl;))> <!ELEMENT imply((%boolExpr.mdl;), (%boolExpr.mdl;))> <!ELEMENT onlyOne((%boolExpr.mdl;)+)> <!ELEMENT ifdef EMPTY> <!ATTLIST ifdef name CDATA#REQUIRED> <!-- G. Values --> <!-- G1. Boolean constants --> <!ELEMENTtrue EMPTY> <!ELEMENT false EMPTY> <!-- G2. String, integer and enumconstants --> <!ELEMENT const (#PCDATA)> <!-- G3. Value is given by thevar (can be any type) --> <!ATTLIST var name CDATA #REQUIRED> <!ELEMENTvar (using)?> <!-- G4. Reference to a variable --> <!ELEMENT ref EMPTY><!ATTLIST ref name CDATA #IMPLIED> <!-- G5. String value. Can referencevariables value (enclosed by {name}) --> <!ELEMENT vstring (#PCDATA)><!-- H. Structures fields --> <!ENTITY % field.mdl’description?,(%type.mdl;), (%expr.mdl;)?’> <!ELEMENTfield(%field.mdl;)> <!ATTLIST field name CDATA #REQUIRED optional(yes|no) #IMPLIED ref-only (yes|no) #IMPLIED> <!-- I. Condition --><!ELEMENT condition (%boolExpr.mdl;)> <!-- J. Declaration of variables--> <!ENTITY % definition.mdl ’description?,condition?,(%type.mdl;),default?, (%expr.mdl;|value*)?> <!ELEMENT definition(%definition.mdl;)> <!ATTLIST definition name CDATA #REQUIREDconfigurable (yes|no) #IMPLIED visible (yes|no) #IMPLIED global (yes|no)#IMPLIED > <!ELEMENT feature (%definition.mdl;)> <!ATTLIST feature nameCDATA #REQUIRED> <!ELEMENT tunable (%definition.mdl;)> <!ATTLIST tunablename CDATA #REQUIRED> <!-- K. Variable assignment --> <!ELEMENT setting(description?,condition?,(%expr.mdl;|value*))> <!ATTLIST setting nameCDATA #REQUIRED visible (yes|no) #IMPLIED > <!-- L. Constraintdefinition --> <!ELEMENT constraint (description?, (%boolExpr.mdl;))><!ATTLIST constraint name CDATA #REQUIRED> <!-- M. Parameter definition--> <!ELEMENT parameter (%expr.mdl;)> <!-- N. Action --> <!ELEMENTaction (description?,condition?,application,(definition|%expr.mdl;))><!ATTLIST action name CDATA #REQUIRED visible (yes|no) #IMPLIED ><!ELEMENT application (#PCDATA)> <!-- O. Definition of types --><!ELEMENT typeDef (description?, (%type.mdl;))> <!ATTLIST typeDef nameCDATA #REQUIRED > <!ELEMENT type EMPTY> <!ATTLIST type name CDATA#REQUIRED ref-only (yes|no) #IMPLIED> <!-- P. Member and list access.--> <!ATTLIST using field CDATA #IMPLIED index CDATA #IMPLIED> <!ELEMENTusing (using)?> <!ELEMENT value (%expr.mdl;|value+) > <!ATTLIST valuefield CDATA #IMPLIED index CDATA #IMPLIED> <!ELEMENT default(const|true|false) > Exhibit II - ECML Fundamentals - Examples II.1.1<definition name=’my_variable’> <bool /> <true /> </definition> II.1.2<definition name=’my_variable2’> <int /> <const>1024</const></definition> II.1.3 <setting name=’my_variable1’> <bool /> <false /></setting> II.1.4 <definition name=’my_variable4’> <int /> <varname=’my_variable2’ /> </definition> II.2 <action name=’my_action’><application>my_application</application> <var name=’my_variable’ /></action> II.3.1 <typeDef name=’my_type’> <struct> <fieldname=’my_field1’> <int /> </field> <field name =’my_field2’> <bool /></field> </struct> </typeDef> II.3.2 <definition name=’my_variable’><type name=’my_type’ /> <value field=’my_field1’>1024</value>. <valuefield=’my_field2’><true /></value> </definition> II.4 <definitionname=’my_variable’> <condition><var name=’my_condition’ /></condition><int /> <const>1024</const> </definition> II.5 <constraintname=’my_constraint’> <var name=’my_condition’ /> </constraint> II.6Boolean Arithmetic <and> <var name=’my_condition1’ /> <varname=’my_condition2’ /> </and> 11.7.1 <folder name=’my_folder’><definition>. . .</definition> . . . <folder name=’my_subfolder1’> . . .</folder> <folder name=’my_subfolder2’> . . . </folder> </folder> II.7.2<folder name=’my_folder’> . . . <folderRef href=’filename’ /> . . .</folder>  1 Exhibit III - Example of a simple ECML file  2  3  4 <?xmlversion=’1.0’?>  5 <!DOCTYPE folder PUBLIC ’-//Sun Microsystems//DTD  6ChorusOS//EN’ ’ChorusOS.dtd’>  7  8 <folder name=’Kernel Configuration’> 9  <folderRef href=’kern_f.xml’ /> 10 11 <folder name=’Core Executive’>12 13 <feature name=’HOT_RESTART’> 14  <description>Hot restartsupport</description> 15  <bool /> 16  <false /> 17 </feature> 18 19<feature name=’USER_MODE’> 20  <description>User mode executionsupport</description> 21  <bool /> 22  <default> <true /> </default> 23 <true /> 24 </feature> 25 26 <feature name=’ROUND_ROBIN’> 27 <description>POSIX round-robin scheduling class</description> 28  <bool/> 29  <false /> 30 </feature> 31 32 <folder name=’Kernel coretunables’> 33 34 <tunable name=’chorusSiteId’> 35  <description>UniqueChorus Site Identifier 36 Needs only to be set if not automaticallyprovided to the kernel 37 by the board-specific boot. 38 WARNING: whenset, must be set with different values within every boot image 39dedicated to different target boards </description> 40  <int /> 41 <const>0</const> 42 </tunable> 43 44 <tunablename=’kern.exec.maxCpuNumber’> 45  <description>Maximum number ofprocessors</description> 46  <int /> 47  <const>1</const> 48 </tunable>49 50 <tunable name=’kern.exec.maxActorNumber’> 51  <description>Maximumnumber of actors</description> 52  <int /> 53  <const>64</const> 54</tunable> 55 56 <tunable name=’kern.exec.maxThreadNumber’> 57 <description>Maximum number of threads</description> 58  <int /> 59 <const>128</const> 60 </tunable> 61 62 63 </folder> 64 65 </folder> 6667 68 <folder name=’Memory management’> 69 70 <folder name=’VirtualAddress Space’> 71 72 <condition> 73  <var name=’VIRTUAL_ADDRESS_SPACE’/> 74 </condition> 75 76 <feature name=’ON_DEMAND_PAGING’> 77 <description>On-demand paging</description> 78  <condition> 79  <and>80   <var name=’VM_available’ /> 81   <var name=’PRM_available’ /> 82 </and> 83  </condtion> 84  <bool /> 85  <false /> 86 </feature> 87 88</folder> 89 90 </folder> 91 92 </folder>

What is claimed is:
 1. A method of configuring software for a target,comprising: a. preparing commands (509) which specify: a1. a subset ofcomponents selected from a group of components, a2. parameters (546) fortuning a least some of the selected components in said subset, and b.preparing an image file (540) from the command file, said image fileconstituting loadable software in a target, wherein step a. compriseswriting said commands in a command file (509) using a singleobject-oriented programming language, capable of managing treestructures of objects.
 2. The method of claim 1, wherein said commandfile (509) is an XML file, and said single programming language isspecified using an XML document type definition (201), having at leastone nestable element predefined to receive an attribute pointing on afile.
 3. The method of claim 2, wherein said XML document typedefinition (201) has a predefined element adapted to form a condition,and has other elements adapted to receive a condition as an attribute,for conditionally processing such other elements.
 4. The method of claim2, wherein said XML document type definition (201) has a predefinedelement adapted to form a constraint, and has other elements adapted toreceive a constraint as an attribute, for conditionally accepting valuesof such other elements.
 5. The method of claim 2, wherein said XMLdocument type definition (201) has a predefined element adapted tolaunch an application with a parameter.
 6. The method of claim 2,wherein said XML document type definition (201) has predefined featureand tunable elements for adapting the configuration.
 7. The method ofclaim 1, wherein the command file (509) and image file (548) areprepared on a host system separate from the target.
 8. A methodaccording to claim 1, further comprising the step of : c. loading (550)the image file in the target.
 9. A method according to claim 1, whereinstep c) further comprises loading (550) the subset of components on thetarget.
 10. The method of claim 1, wherein the image file (550) includesat least an operating system kernel and an operational file system. 11.The method of claim 1, wherein the image file defines (550) parameters,actions, and memory layout of the software.
 12. The method of claim 1,wherein step b) comprises: b1. preparing a make file (535) from saidcommand file, and b2. building said image file (548) using said makefile.
 13. A computer program product, comprising the group of componentsof step a1., the code of the XML document type definition (201) in claim2, and the code for implementing step b.
 14. The computer programproduct of claim 13, further comprising code for implementing step a3.of claim
 8. 15. The computer program product of claim 13, furthercomprising code for implementing step c. of claim
 9. 16. A system forconfiguring software for a target, comprising a host having a. A groupof components; b. Software for preparing a command file (200,509) whichspecifies b1. a subset of components (545,546) selected from the groupof components, b2. parameters (546) for tuning at least some of theselected subset of components, b3. loading (550) of the subset ofcomponents on the target, said software using a single object-orientedprogramming language, capable of managing tree structures of objects, c.Software for preparing an image file (548).
 17. The system of claim 16,wherein said command file (200,509) is an XML file, and said singleprogramming language is specified using an XML document type definition(201), having at least one nestable element predefined to receive anattribute pointing on a file.
 18. The system of claim 17, wherein saidXML document type definition (201) has a predefined element adapted toform a condition, and has other elements adapted to receive a conditionas an attribute, for conditionally processing such other elements. 19.The system of claim 17, wherein said XML document type definition (201)has a predefined element adapted to form a constraint, and has otherelements adapted to receive a constraint as an attribute, forconditionally accepting values of such other elements.
 20. The system ofclaim 17, wherein said XML document type definition (201) has apredefined element adapted to launch an application with a parameter.21. The system of claim 17, wherein said XML document type definition(201) has predefined feature and tunable elements for adapting theconfiguration.
 22. The system of claim 16, further comprising: d. A link(900) for loading the image file and the selected subset of componentsin the target.
 23. A command file from which an image file for a targetcan be prepared, the command file specifying a. a subset of components(545,546) selected from a group of components, b. parameters (546) fortuning at least some of the selected subset of components, c. loading ofthe subset of components on the target.
 24. A computer program productcomprising a computer-readable medium, having a command file (200,509)from which an image file for a target can be prepared, the command filespecifying a. a subset of components (545,546) selected from a group ofcomponents, b. parameters (546) for tuning at least some of the selectedsubset of components, c. loading of the subset of components on thetarget.
 25. The combination of the command file of claim 22 with thecorresponding image file.
 26. An XML processor, comprising: a parser foracquiring at least a portion of an XML type file, and a correspondingdocument type definition (201), and an analyser (211) for identifyingobjects in said portion of said XML type file, said objects comprisingvariables, values, operations, conditions and commands, whereby said XMLtype file may be used as a program file.
 27. A Document Type Descriptionfor an XML type file, comprising a set of definitions of XML elements(201) comprising variables, values, operations, conditions and commands,whereby an XML type file may be used as a program file.
 28. The DocumentType Description of claim 27, further comprising definitions of XMLentities (201), usable in said definitions of XML elements.